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)
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 ( talk • contribs) 09:29, 23 April 2014 (UTC)
There should be a link to a new article on email addresses, that follow other conventions:
[1] would be a good reference, although I'm not sure its a RS. Snori ( talk) 19:47, 3 July 2015 (UTC)
Link: Email address#Local-part the dots altogether is not valid. — Preceding unsigned comment added by Kenorb ( talk • contribs) 10:19, 5 August 2016 (UTC)
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)
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)
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.
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)
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)
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)