Jump to content

Talk:Email address

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

This is an old revision of this page, as edited by 2602:306:cfce:1ee0:3044:a2c3:2683:987b (talk) at 19:35, 5 April 2019 (→‎No addresses commonly used?: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

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 (talkcontribs) 20:53, 12 August 2003 (UTC)[reply]

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 (talkcontribs) 21:03, 12 August 2003 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

Yarr, that be mighty advanced, I appriciate it, however. Thank you 62.20.156.137 19:02, 28 February 2007 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]

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.

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)[reply]

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

Megaboss1234 Hub boss1234 (talk) 19:21, 12 December 2018 (UTC)[reply]

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)[reply]

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)[reply]

"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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

Mr. Kalivd. Please stick to one issue per post Sanjiv swarup (talk) 03:31, 8 June 2008 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]

Tone

Can someone explain why we're using contractions and first person in this article? Ten Pound Hammer and his otters • (Broken clamshellsOtter chirpsHELP) 17:33, 17 October 2008 (UTC)[reply]


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 (talkcontribs) 17:30, 9 January 2009 (UTC)[reply]

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)[reply]


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)[reply]

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)[reply]

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)[reply]

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)[reply]


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)[reply]

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)[reply]

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)[reply]

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)[reply]
Quick look, seems ok still. Be back later. fredgandt 14:47, 2 January 2012 (UTC)[reply]

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

Yup. All good. fredgandt 17:55, 2 January 2012 (UTC)[reply]

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)[reply]

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)[reply]

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 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)[reply]
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)[reply]
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)[reply]
New version at https://fredgandt.com/validator/  fredgandt 22:46, 3 January 2012 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Done BuSchu (talk) 15:20, 2 February 2012 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]


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 (talkcontribs) 06:12, 9 March 2013 (UTC)[reply]

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)[reply]

"......................."@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)[reply]

Combining dot-form with quoted strings?

The article says you can place a quoted string as a fragment of a dot-atom as so: John."Quote".Smith@example.com

However, the relevant section from RFC 5322 reads:

local-part = dot-atom / quoted-string / obs-local-part

dot-atom-text = 1*atext *("." 1*atext)

dot-atom = [CFWS] dot-atom-text [CFWS]

quoted-string = [CFWS] DQUOTE *([FWS] qcontent) [FWS] DQUOTE [CFWS]

Clearly, it states the local part must be either a dot-atom consisting solely of none-quoted atext strings, or a fully quoted string surrounded by quotes at both ends. Where does it allow a combination of the two as stated in the article?

If following the RFC to the letter, the example much."more\ unusual"@example.com shown in the article is NOT valid. If it is valid by a different RFC or section, a relevant reference should be made. At the very least, it should be noted that this form does not conform with RFC 5322 which is referenced in that section of the article.

82.80.149.88 (talk) 09:09, 16 January 2012 (UTC)[reply]

In local-part you have "obs-local-part":

obs-local-part = word *("." word)

word = atom / quoted-string

And this allowed that !. — Preceding unsigned comment added by Sha.tabasi (talkcontribs) 09:29, 23 April 2014 (UTC)[reply]

This is marked as obsolete syntax. According to Section 4 in that same RFC 5322: "Though these syntactic forms MUST NOT be generated according to the grammar in section 3, they MUST be accepted and parsed by a conformant receiver." So creating a new address of this form is a violation of the standard, but refusing to accept an old address with this form is also a violation.
NotTheInferno (talk) 00:14, 25 January 2018 (UTC)[reply]
That still makes them valid email addresses by one definition, though. -- Poromenos (talk) 03:41, 11 February 2018 (UTC)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

Non-Internet email addresses

There should be a link to a new article on email addresses, that follow other conventions:

  • ARPANET: Jim@Washington
  • X400: C=no;ADMD= ;PRMD=uninett;O=sintef;OU=delab;S=Alvestrand;G=Harald
  • PROFS: userid@node
  • Grey Book: USERID@UK.AC.CAM.ENG
  • Lotus Notes: Tyler Hamilton/Sales@Europe
  • CompuServe: 432654,6564
  • DECnet: host::user (e.g. DECWRL::WRL-TECHREPORTS)
  • FidoNET: lenz @ 2:331:113.1
  • uucp: reed!percival!bucket!lisag
  • Banyan StreetTalk (REMA): MS@Server8@Servers [Ed Hirsch@Faculty@Univ]

[1] would be a good reference, although I'm not sure its a RS. Snori (talk) 19:47, 3 July 2015 (UTC)[reply]

Some other address formats if you can find the documentation:
  • ATS
  • cc:mail
  • CTSS
Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:11, 26 November 2015 (UTC)[reply]
I have now created Non-Internet email address
Snori (talk) 21:10, 4 March 2016 (UTC)


Anchor link is wrong

Link: Email address#Local-part the dots altogether is not valid. — Preceding unsigned comment added by Kenorb (talkcontribs) 10:19, 5 August 2016 (UTC)[reply]

Display name

The article currently lacks discussion and examples of e-mail address with display name.

E.g.

My Display Name <m.d.n@google.com>

Anyone who looks to this article for the general rules, will have to look elsewhere.

It's a very low quality article. — Preceding unsigned comment added by 85.167.233.96 (talk) 18:07, 24 October 2016 (UTC)[reply]

I've added a sentence to at least warn the user of what is not covered. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:14, 18 November 2016 (UTC)[reply]

SMTP Extension for Internationalized Email no longer support downgrading

The original SMTP Extension for Internationalized Email provided for downgrading an international address to an ASCII address. However, the most recent version[1] drops that. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:47, 21 August 2017 (UTC)[reply]

Whoops; I misread the article. This has already been taken care of. However, the reference might be useful to other editors. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:09, 24 August 2017 (UTC)[reply]
  1. ^ "Key Changes from the Experimental Protocols and Framework", Overview and Framework for Internationalized Email, sec. 12, doi:10.17487/RFC6530, RFC 6530, The key architectural difference between the experimental specifications and this newer set is that the earlier specifications supported in-transit downgrading. Those mechanisms included the definition of syntax and functions to support passing alternate, all-ASCII addresses with the non-ASCII ones as well as special headers to indicate the downgraded status of messages. Those features were eliminated after experimentation indicated that they were more complex and less necessary than had been assumed earlier.

RFC 5321 nomenclature for client and server

In Simple Mail Transfer Protocol. doi:10.17487/RFC5321. RFC 5321., the term client refers to the program sending the e-mail via SMTP and the term server refers to the program receing the e-mail. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:23, 30 August 2017 (UTC)[reply]

Fully Qualified Domain example

The article lists

fully-qualified-domain@example.com.

as a valid e-mail address. However, no version of the grammar appears to permit the trailing dot; in RFC822, domain is defined as

domain     = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom
atom       = 1*<any CHAR except specials, SPACE and CTLs>

i.e. the grammar expects that there will always be a sub-domain after a '.', and that sub-domain isn't allowed to be empty; nor can an atom contain a '.'.

In RFC2822 and RFC5322, domain instead uses dot-atom:

domain        = dot-atom / domain-literal / obs-domain
dot-atom      = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *("." 1*atext)
obs-domain    = atom *("." atom)
atom          = [CFWS] 1*atext [CFWS]
atext         = AlPHA / DIGIT / "!" / "#" / ...   ; Any (for RFC5322, printable US-ASCII) character except controls, SP, and specials.

But likewise, whether it takes the dot-atom route or the obs-domain route, in neither case does it permit a '.' without a subsequent atom or 1*atext.

So, on what basis is it claimed that

fully-qualified-domain@example.com.

is a legal address? Unless I'm much mistaken, it isn't legal according to the grammar in the RFCs. It might conceivably be accepted by some servers or mail clients, of course, but that's a separate matter. Ajhoughton (talk) 13:49, 3 September 2017 (UTC)[reply]

I was just compiling a lengthy reply on how you are wrong, and that the Backus-Naur form in the RFCs you mentioned by those RFC's own accord give only a lax definition of domains and did not intend to replace the RFC 1035 on domain names, which clearly allows absolute domain names with the trailing dot. But then I found "RFC1123 5.2.18 Common Address Formatting Errors". So yeah I think it's stupid not to allow the trailing dot, but unfortunately you are right and that's the standard. 80.108.8.19 (talk) 22:14, 18 November 2017 (UTC)[reply]

Refs needed for "oddball" valid addresses

I've just reverted Khanhduy62's move of some addreses from Valid to Invalid. I've done so not because I know them to be valid, but because they've been there a long while, and presumably are. What would be really nice is if someone can now dig up refs for each of these oddballs - because frankly they do look invalid, and of course would be rejected now in many contexts regardless of what the RFCs say. - Snori (talk)

It's the RFCs and STDs that determine what is valid. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:52, 31 October 2017 (UTC)[reply]

Recent reversion by 80.108.8.19

IP address 80.108.8.19 recently reverted a change by user:Snori, with the description "Fully qualified domains end with a dot. Reverting the comment-less vandalism". While I would have preferred that user:Snori provide a comment, his removal of the trailing dot from the FQDN was correct: unlike the syntax of RFC 1034[a] and RFC 1035[b], there is no trailing period in the RFC 5321 domain name. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:41, 2 November 2017 (UTC)[reply]

Prevalence of tagged addresses?

Some e-mail servers ignore everything after a plus sign (less commonly, a minus sign) so that the user can hand out different addresses to different organizations and thus know who has sold his address without authorization. Email address#Local-part claims "Note that characters after a plus sign + are generally ignored", which seems too strong. Certainly there are servers that do so, and they may even be common, but they are not the norm. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:00, 18 January 2018 (UTC)[reply]

Quoted space as the full local part?

Currently, the quoted space as the full local part (" "@example.com, or even \ @example.com) is listed as invalid. Does someone know why, since the RFC allows quoted spaces and doesn't say anything about the local part having at least one non-space character? -- Poromenos (talk) 03:48, 11 February 2018 (UTC)[reply]

Style for listing IETF RFC and STD docuuments

Would it be desirable to update the references to use {{IETF RFC}}, {{cite IETF|rfc=}} and {{cite IETF|std=}} instead of plain text and <NOWIKI>text</NOWIKI> blocks? Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:58, 15 January 2019 (UTC)[reply]

No addresses commonly used?

Quoting article:

"This article uses the term email address to refer to the addr-spec defined in RFC 5322, not to the address that is commonly used; the difference is that an address may contain a display name, a comment, or both."

That seems silly in an artcle about email. Why not addresses commonly used? That's what I'm trying to recreate from 3-year-old memories. Just a short section with some typical examples would do. Was it:
(Joe Blow) jblow@acme.com ?
(The "+" section seemed close, but no cigar.)

Also one place jargon should be STRICTLY FORBIDDEN is the table of contents, of which is about half. This article seems designed strictly for sysadmins, etc. Like: display name ?