This is the
talk page for discussing improvements to the
Email address article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1, 2 |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||
|
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 [a] and RFC 1035 [b], there is no trailing period in the RFC 5321 domain name. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 23:41, 2 November 2017 (UTC)
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)
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)
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)
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)
References
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)
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)
"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)
References
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)
"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)
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 (could well be expanded -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 15:34, 28 September 2022 (UTC).
), underscore (_
) and hyphen (-
). [1] Common advice is to avoid using some special characters to avoid the risk of rejected emails. [2]
References
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)
In contrast to unquoted local-parts, the addressesare individually in".John.Doe"@example.com
,"John.Doe."@example.com
and"John..Doe"@example.com
are allowed.
<code>...</code>
pairs; I don't understand what you mean by inlining them.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)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)
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)
[ /rfc/rfc1035 RFC1035for RFC 5325, is malformed; I recommend that you change all of the RFC citations to either {{ IETF RFC}} or
{{
cite ietf|rfc=}}
References
The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [RFC1034], [RFC1035], and [RFC1123]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host.
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)
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)
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.”
I do often enter a display namesuggests that I enter it in a login field. -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 19:26, 3 April 2024 (UTC)
>> 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)
>> 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 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’?
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 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)
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)
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)
FirstName.LastName@EasierReading.org
FirstName.LastName@EasierReading.org
This is the
talk page for discussing improvements to the
Email address article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
Archives: 1, 2 |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||
|
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 [a] and RFC 1035 [b], there is no trailing period in the RFC 5321 domain name. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 23:41, 2 November 2017 (UTC)
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)
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)
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)
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)
References
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)
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)
"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)
References
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)
"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)
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 (could well be expanded -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 15:34, 28 September 2022 (UTC).
), underscore (_
) and hyphen (-
). [1] Common advice is to avoid using some special characters to avoid the risk of rejected emails. [2]
References
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)
In contrast to unquoted local-parts, the addressesare individually in".John.Doe"@example.com
,"John.Doe."@example.com
and"John..Doe"@example.com
are allowed.
<code>...</code>
pairs; I don't understand what you mean by inlining them.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)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)
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)
[ /rfc/rfc1035 RFC1035for RFC 5325, is malformed; I recommend that you change all of the RFC citations to either {{ IETF RFC}} or
{{
cite ietf|rfc=}}
References
The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [RFC1034], [RFC1035], and [RFC1123]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular host.
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)
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)
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.”
I do often enter a display namesuggests that I enter it in a login field. -- Shmuel (Seymour J.) Metz Username:Chatul ( talk) 19:26, 3 April 2024 (UTC)
>> 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)
>> 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 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’?
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 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)
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)
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)
FirstName.LastName@EasierReading.org
FirstName.LastName@EasierReading.org