Talk:Email address/Archive 2

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)

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)


 * 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)
 * That still makes them valid email addresses by one definition, though. -- Poromenos (talk) 03:41, 11 February 2018 (UTC)

Non-Internet email addresses
There should be a link to a new article on email addresses, that follow other conventions: |This would be a good reference, although I'm not sure its a RS. Snori (talk) 19:47, 3 July 2015 (UTC)
 * 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]
 * 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)
 * I have now created Non-Internet email address
 * Snori (talk) 21:10,    4 March 2016 (UTC)
 * Snori (talk) 21:10,    4 March 2016 (UTC)

Anchor link is wrong
Link: Email address is not valid. — Preceding unsigned comment added by Kenorb (talk • contribs) 10:19, 5 August 2016 (UTC)

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

E.g.

My Display Name 

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)


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

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 drops that. Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:47, 21 August 2017 (UTC)


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

RFC 5321 nomenclature for client and server
In, 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)

Fully Qualified Domain example
The article lists



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*

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



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

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)