Talk:Email address

Status of RFC 5322

RFC 5322 is not outdated per the [IETF]; if a PHP validator fails on a quoted local part containing a space then the validator is broken. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:38, 13 December 2020 (UTC)

One thing this article seems to be very strict on is, "this is what the RFCs say", but seem to lack practical warnings against doing what is "technically allowed". One can certainly set up a server and allow someone the mail address of "technically allowed"@example.com, but a huge number of users on the internet will simply not be able to send e-mail to that address (because it is a post year 2000 extension that many providers simply will not deal with). Today, one cannot sent such an outbound e-mail via Google's email services, for one example that I'm able to test right now. (( Even though the allowance is much newer, Internationalized (UTF8) local parts are much more accepted )). Vollink (talk) 19:30, 27 September 2022 (UTC)

I agree that adding a list of technically valid but problematic addresses would be useful, and that Despite the wide range of special characters which are technically valid, organisations, mail services, mail servers and mail clients in practice often do not accept all of them. For example, Windows Live Hotmail only allows creation of email addresses using alphanumerics, dot (.), underscore (_) and hyphen (-). Common advice is to avoid using some special characters to avoid the risk of rejected emails. could well be expanded --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:34, 28 September 2022 (UTC)

A quoted-string as a local-part has been a valid email address since RFC-821 from 1982. I can send email to and receive email from such addresses using both Gmail and Outlook (using a work around for a Gmail bug) and I suspect most other email providers. Quoted-string is not a post year 2000 extension.

Quoted-strings have generally worked in major MTA software for over forty years; since well before the World Wide Web was conceived.

UTF-8 support is comparatively new, only standardized in 2012, but advertised by both Gmail and Outlook. Gene.hightower (talk) 17:25, 19 May 2024 (UTC)

While RFC 6530, 6531, 6532, 6533 are 2012, RFC 5335, 5336 are 2008. BTW, none of those supersede RFC 5321, 5322, which are still current. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 06:17, 20 May 2024 (UTC)

RFC-5335 was EXPERIMENTAL, not a standard or proposed standard. And RFC-5335/RFC-6531 didn't change anything related to quoted-strings; UTF-8 support is a different issue. Gene.hightower (talk) 14:26, 20 May 2024 (UTC)

References

Should cite RFC-5321 as relevant standard for address syntax, not RFC-5322

The syntax for header fields such as ‘From:’ and ‘To:’ include email addresses but also much more stuff. The syntax allowed for Mailbox addresses in SMTP is what most people think of as an “email address.”

Perhaps see [1] for suggested text to explain email address syntax, with citation of correct RFCs.

Does anyone think that an email address includes "group" syntax and "display-name" and the comments and folding white space of RFC 5322. doi:10.17487/RFC5322.? All that stuff can be part of the From: header value, but is not part of any address and is not used to deliver email.

If we can agree on the correct syntax to use, I can take a pass at this article to correct and simplify the text. Gene.hightower (talk) 22:16, 1 April 2024 (UTC)

Some definitions in RFC 5321 refer to definitions in RFC 5322.

I believe that most people think of an e-mail address as what appears in the From: header field; some (expletive deleted) software doesn't even show the mailbox.

However, the Transport section should definitely limit the term to mailbox, including group addresses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:51, 2 April 2024 (UTC)

>> I believe that most people think of an e-mail address as what appears in the From: header field;

So when a web form asks for your email address, you put in “Seymour J Metz <…” starting with the ‘display-name’, then an angle bracket then the ‘addr-spec’? You do not. You put in something matching the ‘Mailbox’ rule from RFC-5321. As would 100 out of 100 people asked, is my guess.

>> some (explitive deleted) software doesn't even show the mailbox.

Some software shows only the ‘display-name’ in the From: header, that does *not* mean that ‘display-name’ is an email address. Or is even part of an email address. Gene.hightower (talk) 14:51, 3 April 2024 (UTC)

You do not. “It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts.”

Actually, I do often enter a display name. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:03, 3 April 2024 (UTC)

@Chatul Email address does not include the display name. Period. And I somehow don't believe that you enter your display name in, say, the Gmail login form[2] where it asks for "e-mail". — kashmīrī ^TALK 17:58, 3 April 2024 (UTC)

Why refute what I never wrote? Nothing in I do often enter a display name suggests that I enter it in a login field. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:26, 3 April 2024 (UTC)

So, no display-name; but what about all the comments and folding white space? Is that part of the email address? Gene.hightower (talk) 20:55, 4 April 2024 (UTC)

RFC-5321 does not have any syntax for "group addresses" - not sure what you're talking about here. Gene.hightower (talk) 18:23, 3 April 2024 (UTC)

An RFC 5321 mailox can identify either an individual mailbox or a group. That's determined by the configuration of the MSA and there is no difference in the syntax. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:26, 3 April 2024 (UTC)

An email address can deliver to an individual or a group, but the syntax is the same. Gene.hightower (talk) 20:57, 3 April 2024 (UTC)

Are we accepting that 'Mailbox' from RFC-5321 should be understood as defining the syntax of an "email address" as discussed in this article?

I think it's fine to discuss message header fields (such as From: and To:) and how email addresses are used within them. Gene.hightower (talk) 21:07, 3 April 2024 (UTC)

>> Some definitions in RFC 5321 refer to definitions in RFC 5322.

They are companion documents, that should not confuse anybody. Gene.hightower (talk) 18:36, 3 April 2024 (UTC)

local-part length limit is incorrect

>> The maximum total length of the local-part of an email address is 64 octets.

Simply not true. Local parts much longer than this are commonly used and work fine with many email providers.

The applicable section of RFC-5321 is 4.5.3.1. ‘Size Limits and Minimums’ where is says: “To the maximum extent possible, implementation techniques that impose no limits on the length of these objects should be used.” Gene.hightower (talk) 00:22, 4 April 2024 (UTC)

Why did you drop the next sentence, "Objects larger than these sizes SHOULD be avoided when possible.", from that quote? That plus section 4.5.3.1.1. 'Local-part', which says "The maximum total length of a user name or other local-part is 64 octets.", ustifies the text in the article. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:03, 4 April 2024 (UTC)

I know that in practice ‘Local-part’s much larger than that are in common use, and work fine. The standard suggests that such long ‘Local-part’s SHOULD be avoided, but does not forbid their use. The statement in the artcle without more context provides no useful information, and seems misleading.

My quote did not “drop” anything. Curious readers should consult the original documents. Gene.hightower (talk) 17:35, 4 April 2024 (UTC)

Declaring that a clear limitation in the RFC provide no usefull information verges on OR.

The proper way to address the discrepancy is for the text to note that there is a discrepancy between the RFC and practice. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:00, 4 April 2024 (UTC)

>> Declaring that a clear limitation in the RFC

Except, this is not the RFC that you maintain defines the syntax of an “email address.” No such length limits are discussed in RFC-5322, so again: what standard should be used to define the syntax? Gene.hightower (talk) 19:51, 4 April 2024 (UTC)

There is no such RFC; I maintained that certain RFCs defined certain terms, e.g., local-part, but never maintained that they defined the specific terms e-mail address and email address. The disagreement is to what terms in the RFCs those terms in the articles should refer. I suggest WP:3PO. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:50, 5 April 2024 (UTC)

I feel like we are not at a standstill; RFC-5321 is clear, and should be the authoritative basis for this article.

RFC-5321 defines ‘Mailbox’ and ‘Address’ and notes that the “two terms are typically used interchangeably.” The definition is: “a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited.”

This is the definition of “email address” as used by this article, is it not? The thing this article is about?

What basis can you cite to use any of the syntactic constructs of RFC-5322 as the definition of “email address?” The closest thing that document defines is ‘addr-spec’ which clearly allows for strings that you seem unwilling to include as valid examples of email address, so at some level you seem to agree that (at least not all) RFC-5322 ‘addr-spec’s are “email addresses.”

To back that up with decades of actual use: only valid RFC-5321 ‘Mailbox’ addresses can be used to send or receive email on the public Internet. Gene.hightower (talk) 17:44, 6 April 2024 (UTC)

Section on local-part syntax incorrect according to RFC-5321 OR RFC-5322.

>> Comments are allowed with parentheses at either end of the local-part

RFC-5322 allows comments, white space, and “folding” white space (CRLF followed by a space or tab) between any tokens, except “Comments and folding white space SHOULD NOT be used around the "@" in the addr-spec.”

RFC-5321 allows no comments at all. Gene.hightower (talk) 00:42, 4 April 2024 (UTC)

The text should make the context clear. In RFC 5321, Mailbox, used in Forward-path and Reverse-path, does not allow comments or white space anywhere.

In RFC 5322, mailbox allows CFWS only prior to the "<". A mailbox given as an addr-spec rather than as a name-addr may not contain CFWS.

Neither RFC defines email address or e-mail address.

Similarly, the text should reflect differences between RFC 6531 and RFC 6532, which obsolete RFC 5336 and RFC 5337. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:49, 4 April 2024 (UTC)

>> In RFC 5322, mailbox allows CFWS only prior to the "<"

In RFC-5322 an ‘addr-spec’ (which is what comes *after* the left angle

bracket in an ‘angle-addr’) starts with a ‘local-part’ which can be a

‘dot-atom’ which is an optional CFWS followed by a ‘dot-atom-text’

So, CFWS can appear on *both* sides of the "<". Gene.hightower (talk) 17:11, 4 April 2024 (UTC)

>> Neither RFC defines email address or e-mail address.

And this may be the root of the confusion for many people. The grammar

rule that maps to a conceptual “email address” is called ‘Mailbox’ in

RFC-5321, and is called ‘addr-spec’ in RFC-5322. Gene.hightower (talk) 17:16, 4 April 2024 (UTC)

You are correct about RFC 5322 dot-atom allowing CFWS, subject to the restriction in 3.4.1. 'Addr-Spec'. Specification.

No, the appropriate terms are Mailbox in RFC 5321 and mailbox in RFC 5321 (the terms differ in case.) Further, if you use the RFC 5321 definition, then all the text about comments is wrong. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:55, 4 April 2024 (UTC)

I agree — I suspect that nobody expects comments are allowed in an “email addresses.” Nor the ‘display-name’.

This is my main point and the crux of the matter.

What is an “email addresses”?

https://digilicious.com/mailbox-address-syntax.html Gene.hightower (talk) 18:26, 4 April 2024 (UTC)

>> […] mailbox in RFC 5321

Except the article says:

>> The term email address in this article refers to just the addr-spec […]

This seems like a contradiction. Gene.hightower (talk) 18:30, 4 April 2024 (UTC)

>> The text should make the context clear.

Except mixing syntax from both RFC-5321 and RFC-5322 when all we need to discuss the syntax of an “email address” is RFC-5321 causes very confused text throughout this article. Gene.hightower (talk) 17:18, 4 April 2024 (UTC)

I believe that there is a fundamental disagreement on what we need to address. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:55, 4 April 2024 (UTC)

How do we resolve this fundamental disagreement? Gene.hightower (talk) 18:27, 4 April 2024 (UTC)

I would suggest WP:3PO. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:44, 5 April 2024 (UTC)

This is a link to an opinion you may find helpful:

<https://github.com/whatwg/html/issues/4562?notification_referrer_id=MDE4Ok5vdGlmaWNhdGlvblRocmVhZDQ4NjUyNTcyNDozOTU3ODEx&notifications_query=reason%3Aparticipating#issuecomment-1987363147> Gene.hightower (talk) 13:57, 5 April 2024 (UTC)

>> Neither RFC defines email address or e-mail address.

But RFC-5321 defines the syntax for the “string that identifies a user to whom mail will be sent or a location into which mail will be deposited.” — that is the ‘Mailbox’ grammar rule from Section 4.1.2. Gene.hightower (talk) 19:55, 4 April 2024 (UTC)

>> Neither RFC defines email address or e-mail address.

From RFC-5321 section 2.3.11. Mailbox and Address:

“As used in this specification, an "address" is a character string

that identifies a user to whom mail will be sent or a location into

which mail will be deposited. The term "mailbox" refers to that

depository. The two terms are typically used interchangeably […]”

So defines Address and Mailbox. Gene.hightower (talk) 20:22, 4 April 2024 (UTC)

RFC 5322 defines address as mailbox / group.

The terms the article uses should be tied to the relevant definitions in the RFCs. In particular, the discussion of Transport should be tied to RFC 5321 and the discussion of header fields and CFWS' should be tied to RFC 5322. Also, the lead should make it clear whether group addresses are in scope. -- Shmuel (Seymour J.) Metz Username:Chatul (talk)

Is the addr-spec syntax of RFC 5322 really what we want?

>> The term email address in this article refers to just the addr-spec in Section 3.4 of RFC 5322.

Okay, can we include some additional examples of “Valid email addresses” according to that definition?

jane.doe@-lax-domain-
jane.doe@[Almost-anything-goes-here!]

If we accept the basic definition of “email address” from the first section of this article, don't we have to accept these examples as valid? These examples are valid RFC-5322 ‘addr-spec’s, but not valid RFC-5321 ‘Mailbox’s. Gene.hightower (talk) 21:27, 4 April 2024 (UTC)

Does anybody want to refute these examples as “valid email addresses” based on the syntax defined by RFC-5322 ‘addr-spec’?

Fun fact: a valid RFC-5321 ‘Mailbox’ address is always a valid RFC-5322 ‘addr-spec’, because the syntax allowed by RFC-5321 is a subset of that allowed by RFC-5322. Gene.hightower (talk) 23:18, 4 April 2024 (UTC)

I believe that the article should state that e-mail address refers to either Mailbox (RFC 5321, only in Transport section) or to mailbox (RFC 5322), and that the article should give separate lists of valid and invalid addresses. I also believe that it should mention that some forms are obsolete, e.g., source routing.

What about International email addresses? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:05, 11 April 2024 (UTC)

We should note that RFC-6531 extends the ‘Mailbox’ grammar rule (of RFC-5321) to include UTF-8. Gene.hightower (talk) 23:12, 15 April 2024 (UTC)

RFC-5322 defines syntax for both ‘address’ and ‘mailbox’; and in that document, they are not the same thing. Neither are an “email address.” Use of these words as names for the derivation rules in the syntax seems to cause confusion, they're just names for rules in the grammar.

The only text strings that define an “email address” are the ‘Local-part’ and ‘Domain’ of RFC-5321, which correspond to the ‘local-part’ and ‘domain’ of RFC-5322. These two strings joined by an ‘@’ character (code point decimal 64) are, in both documents, what people know as an “email address.”

All of the text that may appear inside a message header field beyond ‘local-part’ and ‘domain’ have no semantic value. That includes the ‘display-name’ and the ‘group-list’ and any comments and/or white space.

RFC-5322 says: “The local-part portion is a domain-dependent string. In addresses, it is simply interpreted on the particular host as a name of a particular mailbox.” Clearly indicating in RFC-5322 that the ‘local-part’ and ‘domain’ alone define a mailbox. — Preceding unsigned comment added by Gene.hightower (talk • contribs) 17:52, 15 April 2024 (UTC)

Neither RFC 5321 nor RFC 5322 define email address or e-mail address.

Do you have any objection to WP:3O? --

Neither document uses the exact term “email address” but, read section 2.3.11 of RFC-5321 and ask: what is it defining? It defines both ‘Mailbox’ and ‘Address’ and defines them as synonyms. Check that definition vs. the definition on this Wikipedia page. Is this not an “email address”? — Preceding unsigned comment added by Gene.hightower (talk • contribs) 22:17, 15 April 2024 (UTC)

No, it does NOT define them as synonyms; in fact, it does not define address at all. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:52, 16 April 2024 (UTC)

You are right, they are not synonyms, but the document notes that "The two terms are typically used interchangeably [...]"

I stand corrected. Gene.hightower (talk) 00:36, 17 April 2024 (UTC)

2.3.11. Mailbox and Address

As used in this specification, an "address" is a character string

that identifies a user to whom mail will be sent or a location into

which mail will be deposited. The term "mailbox" refers to that

depository. The two terms are typically used interchangeably unless

the distinction between the location in which mail is placed (the

mailbox) and a reference to it (the address) is important. An

address normally consists of user and domain specifications. The

standard mailbox naming convention is defined to be "local-

part@domain"; contemporary usage permits a much broader set of

applications than simple "user names". Consequently, and due to a

long history of problems when intermediate hosts have attempted to

optimize transport by modifying them, the local-part MUST be

interpreted and assigned semantics only by the host specified in the

domain part of the address. Gene.hightower (talk) 00:39, 17 April 2024 (UTC)

Another indication that RFC-5321 considers ‘Mailbox’ an “email address” is this passage, from section 4.1.2. Command Argument Syntax: «If this string is an email address, i.e., a Mailbox, then the "xtext" syntax [39] SHOULD be used.» Where “i.e.” stands for id est, which is Latin for “that is.” — Preceding unsigned comment added by Gene.hightower (talk • contribs) 23:14, 15 April 2024 (UTC)

We have a strong opinion from Kashmiri that “email address” does NOT include the ‘display-name’ of RFC-5322. — Preceding unsigned comment added by Gene.hightower (talk • contribs) 23:31, 15 April 2024 (UTC)

Mixed case

I have tries to add an example of mixed case which greatly helps readability.

• FirstName.LastName at sign EasierReading.org (case is always ignored after the @ and usually before)

But because it includes a (made-up) e-mail address, the submission system thinks it's spam. How do I get past that? TechColab (talk) 11:17, 16 April 2024 (UTC)

That's a question for the operators of the server that classified it as spam. What messages did you get?

I would suggest adding it to the article. If you have a RS that some servers mis-classify it as spam, cite that source. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:54, 16 April 2024 (UTC)

I've done it now using the HTML entity for the at. None of the existing examples have used it but may have been created before things were tightened. TechColab (talk) 17:13, 16 April 2024 (UTC)

Are you talking about a problem getting the message delivered to that address or a problem rendering it in wiki?

• <code>FirstName.LastName@EasierReading.org</code> renders as FirstName.LastName@EasierReading.org
• <code>FirstName.LastName&commat;EasierReading.org</code> renders as FirstName.LastName@EasierReading.org

I don't see a difference between them. Or is the rendering browser dependent? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 18:10, 16 April 2024 (UTC)

I couldn't get it submitted as an example rendering of a valid e-mail address, seemingly because the 'at' triggers anti-spam blocking. It rendered fine in the preview either way. It's not a real address. I was not trying to get e-mails sent there. In the rendered page they look the same. In the Edit view, the others are at signs but I had to use the entity. Doesn't matter now. 93.191.204.229 (talk) 21:48, 16 April 2024 (UTC)

Abbreviation for the term "email address"?

Is there an abbreviation for the term "email address", like e.g. "ema"? Google had no answer.
Steue (talk) 14:21, 11 August 2024 (UTC)

WP:NOTFORUM — kashmīrī ^TALK 19:24, 22 August 2024 (UTC)

Quero adicionar outro e-mail novo eu não te vi acesso ao antigo

Adicionar outro e-mail 2804:14C:5983:8B63:DF6F:E269:2856:E0F3 (talk) 13:33, 12 September 2024 (UTC)

Interested I need morning

James David 2001,1,12 102.91.93.204 (talk) 13:35, 14 September 2024 (UTC)

12.1.20001 102.91.93.204 (talk) 13:38, 14 September 2024 (UTC)

10200 202.94.164.162 (talk) 22:31, 1 October 2024 (UTC)

Hajara Usman @12345

Hajara Usman 105.112.124.19 (talk) 14:29, 27 October 2024 (UTC)

@ 179.48.229.64 (talk) 05:03, 4 November 2024 (UTC)

11734947586 2804:4D28:1010:128:F95D:4968:21C0:93C8 (talk) 23:20, 6 November 2024 (UTC)

11734947586

Geovane Silva Santos 2804:4D28:1010:128:F95D:4968:21C0:93C8 (talk) 23:22, 6 November 2024 (UTC)

Eu não sei como

Eu não sei como fazer 2804:4D28:1010:128:F95D:4968:21C0:93C8 (talk) 23:23, 6 November 2024 (UTC)