Talk:Email address/Archive 2

Archive 1

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:

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

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)

Anchor link is wrong

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)

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)

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

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)

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)

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 and RFC 1035, there is no trailing period in the RFC 5321 domain name. Shmuel (Seymour J.) Metz Username:Chatul (talk) 23:41, 2 November 2017 (UTC)

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)

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)

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 ?
— Preceding unsigned comment added by 2602:306:CFCE:1EE0:3044:A2C3:2683:987B (talk) 19:35, 5 April 2019 (UTC)

When the nomenclature in an article on a technical subject differs from that in the literature, then the text should make that clear. The usage of "address" in the article matches the definition of "mailbox" in RFC 5321, not the definition of "address" in RFC 5322.

Per the definitions in RFC5321 and FC5322, "Foo Bar <foo@bar.com>" is an address; "<foo@bar.com" is both an address and a mailbox. Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:17, 21 August 2019 (UTC)

References

Edit by 117.237.210.103

Could the edit by 117.237.210.103 be referring to source routing as one of the three parts of an address? Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:40, 11 October 2019 (UTC)

@Chatul: I think you mean the edits by PremKwiki (talk · contribs); the IP just undid one of the edits and I undid the other one. The text at the URL in their edit summary listed the "@" character as the second part. I wouldn't call it incorrect, but I think the original text of the article better matches the common usage of the term "part" and as a result is more understandable. –LiberatorG (talk) 21:06, 11 October 2019 (UTC)

Please read the relevant RFCs before making changes based on what the editor presumes is in them

The article has links to, e.g., RFC 5321, RFC 5322; it's not that difficult to read them instead of making incorrect changes based on assumptions. Shmuel (Seymour J.) Metz Username:Chatul (talk) 01:53, 23 February 2020 (UTC)

'Dot-string'?

"A local part is either a Dot-string or a Quoted-string..." - have no idea what a dot string is. Guesses don't count.

Refactoring, or a 'Dot-string' link would be useful / appreciated. — Preceding unsigned comment added by Bs27975 (talk • contribs) 16:58, 23 July 2020 (UTC)

Those are definitions in RFC 5321. There are multiple citations of that document, with different sections, different quotations, or both, and I'd like to cut out the redundancy without losing information, but I'm not sure how best to retain the functionality of {{cite IETF}} while rendering the common information only once. Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:21, 23 July 2020 (UTC)

References

include examples with subdomains?

As far as I understand the introduction "With the introduction of internationalized domain names, efforts are progressing to permit non-ASCII characters in email addresses." it also means that anything after the @ is either different from a valid domain name or at least only a true subset. Yet all examples only differs in anything before the "@" - and the comment in brackets. Would it be useful to just inline "john.doe@sub.example.com"? --2001:A62:1963:BA01:B880:2BA:CCE8:633D (talk) 14:18, 22 July 2021 (UTC)

No, it means that some addresses are now allowed with SMTPUTF8 that are invalid without it; it doesn't mean that every domain must have non-ASCII characters. The first example in Email address#Internationalization examples has a domain that is pure ASCII.

The examples in Email address#Local-part all have the same domain. The addresses in In contrast to unquoted local-parts, the addresses ".John.Doe"@example.com, "John.Doe."@example.com and "John..Doe"@example.com are allowed. are individually in <code>...</code> pairs; I don't understand what you mean by inlining them.

As for "john.doe@sub.example.com", john.doe@sub.example.com has an unquoted local part and doesn't belong in that sentence. If you want an example of a three level domain, the place to put it is Email address#Examples. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:17, 22 July 2021 (UTC)

Incorrect part: no underscores in domain name

The example of a "bad email address" show this example: i_like_underscore@but_its_not_allowed_in_this_part.example.com. That doesn't seem to be correct as per RFC 2181, section 11, "Name syntax", as stated here. Also see rfc3696, sub 2: "Any characters, or combination of bits (as octets), are permitted in DNS [=domain] names." It continues: "However, there is a preferred form [...] the "LDH rule", [that] provides that the labels (words or strings separated by periods) that make up a domain name must consist of only the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen." So, while preferred, it's not required. JHBonarius (talk) 08:29, 19 August 2021 (UTC)

In every way I read RFC 2181, section 11 (the section above quoted ), is specific to non-hostname resource records and those, in turn MIGHT include labels from hostname record types. That is, it's fine to have a weird binary string as a non-hostname resource record's label, but that doesn't automatically apply to MX, CNAME, A, or AAAA DNS records. But absolutely are used for things like TXT records (which are not expected to point to a hostname). That is, pay close attention to the first paragraph of that section. Vollink (talk) 19:09, 27 September 2022 (UTC)

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)

• Yes. Even if it isn't today, it could become so in the future. Andy Dingley (talk) 21:20, 15 January 2019 (UTC)

  Should every mention of an RFC use {{IETF RFC}} or only the first in each section? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:50, 22 January 2023 (UTC)

Address literal instead of Internet domain name

I was reading the actual RFC for email and noticed it stopped mentioning allowing numerical values starting with RFC 2822. Prior RFCs (like RFC 822) had this language in their address specification section:

Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
    is  permitted  only  as  a means of bypassing temporary
    system limitations, such as name tables which  are  not
    complete.

This language is present in earlier RFCs, but this language disappears in 2822, and is also not present in 5322. There is a section in the addr-spec in 5322 that says:

 Note: A liberal syntax for the domain portion of addr-spec is
 given here.  However, the domain portion contains addressing
 information specified by and used in other protocols (e.g.,
 [RFC1034], [/rfc/rfc1035 RFC1035], [RFC1123],   [RFC5321]).  It is therefore
 incumbent upon implementations to conform to the syntax of
 addresses for the context in which they are used.

The RFC for the SMTP protocol, RFC5321 does have a section about using address literals in the domain portion Address Literals.

Some email clients will let you enter an address with address literals, but a lot do not. Some mail delivery subsystems will have problems with delivering mail in that format as well., particularly if there is mailbox ambiguity due to a mail server being responsible for multiple domains.

Generally to me, it seems that while SMTP does support address literals, it is not generally used or advised for actual user use for email addresses. My original intention on removing those sections were to steer people away from thinking this was a valid format, as it isn't given 5322. But it also IS valid for SMTP, and with the section about conforming to the syntax of the addresses for the context used, it's a little unclear how it should be handled. This page seems to be mostly focused on the addr-spec definition of an email address, which I think means it should mention how address literals are not really intended in that format since it does not appear in the addr-spec anymore. What do others think? Maybe I am missing something obvious? I am a novice at wiki so I figure the more experienced powerusers might have good input here. Martianant (talk) 00:17, 12 May 2023 (UTC)

One of the links that you provided, i.e., [/rfc/rfc1035 RFC1035] for RFC 5325, is malformed; I recommend that you change all of the RFC citations to either {{IETF RFC}} or {{cite ietf|rfc=}}

While some language deprecating it is gone, RFC 5322 still includes domain-literal and language describing the use of IP addresses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 09:48, 12 May 2023 (UTC)

Even though SMTP is able to handle domain literals, such a use is not likely to work in most scenarios where DNS-based security mechanisms (such as SPF, DKIM and DMARC) have been implemented as recommended by relevant RFCs. In effect, SMTP will correctly handle a message with domain literals in the Sender or Envelope-sender header, but more often than not the message will be rejected by downstream MTAs. — kashmīrī ^TALK 11:04, 12 May 2023 (UTC)

There are two different IP questions that the article should discuss:

1. Is it valid to use an IP address as the domain part?
2. Is it prudent to have an IP address as the domain part?

IMHO, while the answer to the first is yes, the answer to the second is an empatic no; some e-mail operators regard a bare IP address as a red flag and will reject messages containing such mailbox references. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:25, 12 May 2023 (UTC)

I think it's valid and it's also valid for correctly configured MTAs not to deliver such messages. Such a small contradiction in the vast body of RFAs. — kashmīrī ^TALK 11:44, 12 May 2023 (UTC)

There is no contradiction; RFC 5321 is quite clear that "My server, my rules" applies to classifying attempted deliveries; look for "policy reasons". You are, of course, required to use the correct code to indicate rejection. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:52, 12 May 2023 (UTC)

References