Talk:Email address/Archive 2

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

Combining dot-form with quoted strings?[edit]

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 (talk • contribs) 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]

Non-Internet email addresses[edit]

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[edit]

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

Display name[edit]

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[edit]

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[edit]

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[edit]

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[edit]

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]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Email_address/Archive_2&oldid=1196754237"