Jump to content

Talk:Email address/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2

The Need for E-mail

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.

Having your own e-mail address is considered an essential part of life in cyberspace and is required for almost everything other than viewing pages. Making online purchases, subscribing to paid content, posting in web logs or Internet forums, participating in Usenet newsgroups and many other tasks will require a valid e-mail address. Despite once being considered part of "geek culture", not having an e-mail address can seriously disadvantage a person. For this reason, many governments in modern countries are undertaking initiatives to give e-mail addresses to public servants and school children.

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.

Complexity of email addresses

Under "Invalid email addresses" it says

  1. this is"not\allowed@example.com (spaces, quotes, and backslashes may only exist when within quoted strings and preceded by a backslash)
  2. this\ still\"not\\allowed@example.com (even if escaped (preceded by a backslash), spaces, quotes, and backslashes must still be contained by quotes)

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):

Yeah, something needs to be done about this. If the below grammar doesn't describe an email address (as per the article title), then what does it describe? 207.14.29.3 (talk) 18:16, 17 December 2013 (UTC)
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]

Perl's RFC2822 email regex

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)

Yarr, that be mighty advanced, I appriciate it, however. Thank you 62.20.156.137 19:02, 28 February 2007 (UTC)
May be helpful to note that RFC 5322 obsoletes RFC 2822. For notation, RFC 5234 describing an Augmented Backus-Naur Form, is cited by 5322. Regards, ... PeterEasthope (talk) 14:55, 11 August 2011 (UTC)

Moved comment from main article to talk page

The following was found at the end of the "plus (or minus) addressing" section:

"The reason why gmail.com and qmail support are different systems, or pro's and cons have yet to be fully explained."

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)

English Language ??

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.

"Common usage" isn't the same as "correct usage".

References

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)

I restored the link to one that was used earlier. The regular expression listed there still isn't right though, as it rejects various parts where stuff like UTF-8 is allowed. As mentioned about in #Complexity of email addresses, this really is a very nasty problem. Wrs1864 20:59, 17 January 2007 (UTC)


plus signs

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".

I recommend this statement:
I have listed your website at http://mozilla.wikia.com/wiki/User:Me_at_work/plushaters#Plus_haters as it does not conform with accepted Internet email standards AND does not assist in the prevention of spam and address reselling

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)

The same considerations apply to other special characters, e.g., minus sign, braces. In addition to use for spam traps, I used to use "plussed" addresses to let my e-0mail software automatically route messages from different sources to different folders, and others have used minus signs for similar purposes.

"User" vs. User

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)

A number of characters (roughly, anything apart from the usual alphanumerics and common punctuation) must be quoted if they appear in the display-name part of an address. Most notably, RFC 2822 does not include the dot (period / full stop) in that common punctuation - you don't need quotes for J Public <jpublic@domain.tld>, but you do need them for "J. Public" <jpublic@domain.tld>. Because characters that need quoting are very common, especially with an international audience, it's simpler and safer to quote everything. (A legal unquoted display-name never changes if you quote it, but lots of quoted ones become illegal if you take the quotes away.)
I don't know why you think quoted names are outdated - they're still current as far as I know. Are you perhaps confusing them with the old address@domain.tld (Display Name) form? That's certainly outdated (it might still be legal under RFC 2822's CFWS rules, but don't quote me on that, and it would render the bracketed Display Name meaningless anyway), but I don't know of anything that still uses it...
-- 210.54.3.3 (talk) 06:19, 29 October 2008 (UTC)
Thanks, now I know why mailman uses this syntax for its bulk email insertion (and this answers your query about it still being used :-) ). Mark Hurd (talk) 15:04, 2 September 2010 (UTC)

un structured comments

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)

I have put these un structured comments inside a sub section . Will the author please explain himself.

Otherwise , these comments may be deleted

Sanjiv swarup (talk) 03:36, 8 June 2008 (UTC)

Limitations and Validation part of the same thing?

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)

I think they are different enough topics that they should stay separate. I changed the section name from "limitations" to "detailed definition" to try to make this distinction clearer. Wrs1864 (talk) 17:42, 6 June 2008 (UTC)
The "limitations" title comes directly from the RFCs themselves. "Restrictions" is be a better term as per RFC 3696. You must bare in mind that the restrictions any kind of email address validation (not to be confused with verification) is based on. --Hm2k (talk) 18:29, 6 June 2008 (UTC)
Well, I disagree that either "limitations" or "restrictions" are good names for that section. It defines what a valid e-mail address looks like. Yes, technically, any definition is a restriction/limitation, but that is kind of meaningless. RFC 3696 uses "restrictions", but as a complaint about broken validators that cause needless restrictions. I still think that definition the section based on what something is, rather than what it is not, is a better way to go. Wrs1864 (talk) 18:46, 6 June 2008 (UTC)
RFC 2822 calls it "specification", however the section in question only really talks about the "limitations", or as RFC 3696 describes them, "restrictions". I have no reason to believe any other title is appropriate. --Hm2k (talk) 11:10, 7 June 2008 (UTC)
Additionally, you will understand that the "restrictions" or "specification" are used for one thing, and one thing only, that is "validation". Which begs the question, is it just a subsection of "validation"? --Hm2k (talk) 11:10, 7 June 2008 (UTC)
Yes, I think that the word Restrictions is not the right one to use instead it can always be a subsection of Validation and Verification.

Kalivd (talk) 14:46, 7 June 2008 (UTC)

If you think about the "examples" that are provided, they are valid examples for the restrictions, limitations, validation and verification. Thus need to be all tied in together. I will make this so. --Hm2k (talk) 09:17, 12 June 2008 (UTC)

See also

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)

Mr. Kalivd. Please stick to one issue per post Sanjiv swarup (talk) 03:31, 8 June 2008 (UTC)
Be Bold WP:BOLD and add the links. Just remember to follow WP:SEEALSO. It is always a good idea to have the wikipedia articles inter-linked for easy navigation. Dhshah (talk) 07:05, 8 June 2008 (UTC)
Well thanks for the suggestion, here on i would stick to one issue per post 59.92.138.194 (talk) 15:22, 9 June 2008 (UTC)
Clicking the the "e-mail" category is a far more effective way of navigating than listing all marginally related e-mail related articles to the see also link. As the WP:SEEALSO page says, links are better inline. Wrs1864 (talk) 15:52, 9 June 2008 (UTC)

Difference between Validation and Verification

"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)

Corrected Missing Hyphenation in This Article

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)

The request to discuss that section was due to incorrect changes to that section, as discussed above, however this request no longer really applies as no further incorrect edits have been made since. --Hm2k (talk) 17:42, 15 August 2008 (UTC)

Tone

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)


User validation vs MIME validation

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)

Restrictions on E-Mail Adresses

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)

Reference 6 is dead

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)

Thank you for your suggestion. When you believe an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the edit this page link at the top. The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. You don't even need to log in (although there are many reasons why you might want to). --Hm2k (talk) 07:17, 29 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)

Clarify SMTP server / DNS lookup

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)

A contradiction?

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)

The errata to rfc 3696 may shed some light. It is extremely difficult stuff to wade through, but I can assure you, the article was correct when I updated it to this version. Since then it has suffered some vandalism and other changes, but should still be correct. I'll give it a good going over in a little while (was just about to take the dog out). fredgandt 14:36, 2 January 2012 (UTC)
Quick look, seems ok still. Be back later. fredgandt 14:47, 2 January 2012 (UTC)

Thanks! If I had read the line to the end ... ;-) --BuSchu (talk) 15:39, 2 January 2012 (UTC)

Yup. All good. fredgandt 17:55, 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)

Email syntax validator

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)

I think that the way to do this would be to first point to a Reputable Source such as http://www.w3schools.com/php/filter_validate_email.asp as an example of how rather than attempting a roll-you-own validation, libraries/filters are the best way - then perhaps link to your site as an example of actual use. Note that com/od/emailprogrammingtips/qt/How-To-Validate-Email-Addresses-In-A-Php-Script.htm FILTER_VALIDATE_EMAIL isn't perfect - try test@e111111111112222222222233333333333444444444445555555555666666.com - then add a a few extra characters to the domain name. Snori (talk) 18:30, 2 January 2012 (UTC)
I'm guessing that's a known bug? (I have yet to look at the link) Is it as specific as I think it might be (I think it's very specific)? If there is a better validator (which apparently won't be hard to find), then of course it should be used over mine. I just wanted to provide one with no commercial overtones. Ah, I see the w3Schools is just an example. I'll leave the decisions up to other editors (per WP:COI) about what to add in this respect. I do think the page could do with some way to literally validate its claims (the ultimate reference). Embedded in the page would be even better. fredgandt 18:42, 2 January 2012 (UTC)
Ok they are known bugs. I'll rewrite after sleeping. I tried to keep it as simple as possible on purpose. Usually there's a check of the mx filesrecords (I'm tired) for the domain name and a load of other stuff too, but that wouldn't have been syntax checking. I'll be back! fredgandt 18:47, 2 January 2012 (UTC)
New version at https://fredgandt.com/validator/  fredgandt 22:46, 3 January 2012 (UTC)

the possibility of comments is missing

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)

It isn't something I was aware of but a quick googling revealed this, which may or may not prove the possibility exists. More references would be needed, and preferably not to books (I think are) about spamming. fredgandt 18:13, 3 January 2012 (UTC)
Now I've tried it with several providers (web.de, gmx.de gmail.com). The results:
web.de doesn't allow an address like "prename(comment).lastname"@<someprovider>
gmx.de and gmail.com accept such addresses, but the mails come back as undeliverable. BuSchu (talk) 10:48, 4 January 2012 (UTC)
According to RFC 2822 I think that this is the specification for the full address and is something like:
"name" <address> (comment)
for example "John Smith" <john.smith@test.com> (home email)
-- Q Chris (talk) 11:38, 4 January 2012 (UTC)
Now, after reading Appendix A.5 of RFC5322 I tried something like john.smith(comment)@gmail.com from gmx.net, and it was sent perfectly to john.smith@gmail.com (GMX told me the removing of the comment!). Some comments are really possible. Should be mentioned with the correct rules for comments! BuSchu (talk) 16:12, 12 January 2012 (UTC)
Feel free to amend the article. See https://tools.ietf.org/html/rfc5322#section-3.2.2 (and all related sections) and be bold! fredgandt 16:29, 12 January 2012 (UTC)
Done BuSchu (talk) 15:20, 2 February 2012 (UTC)
"comments are allowed with parentheses at either end of the local-part; " might be wrong. RFC 5322 3.2.1 specifies:
address = mailbox / group
mailbox = name-addr / addr-spec
name-addr = [display-name] angle-addr
angle-addr = [CFWS] "<" addr-spec ">" [CFWS] /obs-angle-addr
CFWS means Comment or Whitespace. According to the specification, CFWS (comments) are only allowed before and after the actual email address in angel brackets, but not before display-name. However, I don't know if in reality some software has implemented differently.
PeterHuber (talk) 11:18, 23 February 2020 (UTC)
"comments are allowed with parentheses at either end of the local-part" 'is wrong, but

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.

would be correct. Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:11, 23 February 2020 (UTC)
No, RFC 5322 has
quoted-string   =   [CFWS]
                    DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                    [CFWS]
local-part      =   dot-atom / quoted-string / obs-local-part
which allows comments at either end of a quoted local-part, but does not treat parentheses within the quotes as delimiting comments; it does not allow CFWS on either end of an unquoted local-part.

Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:11, 23 February 2020 (UTC)

you are right. I guess like most people I have not noticed that this article is only about "rfc5322 3.4.1. Addr-Spec Specification", which specifies only the part within angle brackets. So the question is then: Why is this article not about "rfc5322 3.4 Address Specification" ? I guess because this would also include groups, which most people are not interested in. But most people have seen addresses like "John Doe"<John.Doe@example.com> and might wonder why is this a legal email address ? PeterHuber (talk) 09:07, 24 February 2020 (UTC)
Well, my preference would be for the article to describe both and to use the nomenclature from RFC 5321, 5322. Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:35, 26 February 2020 (UTC)

examples

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)

In order for that address to be correct, it would have to not be that address. An address that would be correct is "(),:;<>[\\]"@example.com or "\"(),:;<>[\\]\""@example.com or of course a vast number of alternatives. The domain part is perfectly fine, syntax wise (although example.com doesn't have any mx records) fredgandt 12:59, 4 January 2012 (UTC)
Yes, I agree, "(),:;<>[\\]"@example.com is a correct address, but the original example starts with a quote character quoting the at sign, so there is no domain part ... ;-) BuSchu (talk) 15:16, 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)

2 consecutive dots inside a quoted string allowed?

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)

"......................."@fredgandt.com is acceptable. Quoted strings are not subject to the rulings on dot separation of parts. Dots in quoted strings are just characters, not delimiters. fredgandt 15:47, 4 January 2012 (UTC)

Source for details in local part

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)

I agree that I cannot find a RFC stating the \ must be applied within a string in double quotes ". But RFC rfc3696 says
that the following email addresses are valid:
The exact rule is that any ASCII character, including control
characters, may appear quoted, or in a quoted string. When quoting
is needed, the backslash character is used to quote the following
character. 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
PeterHuber (talk) 08:38, 24 February 2020 (UTC)

E-mail format

email@-domain.com

email@domain.web is valid or not

[huh?]

E-mail length

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)

That was a mistake. Read the errata. — Preceding unsigned comment added by 91.108.160.12 (talk) 11:24, 26 October 2012 (UTC)

Confusing, apparently contradictory section

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?

That's a subset of !#$%&'*+-/=?^_`{|}~

QuentinUK (talk) 14:41, 14 November 2012 (UTC)

Internationalization

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)

  1. ^ http://tools.ietf.org/html/rfc2822
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Email_address/Archive_1&oldid=1246283515"