This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of
computers,
computing, and
information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the
Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet articles
This article is within the scope of WikiProject Technology, a collaborative effort to improve the coverage of
technology on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.TechnologyWikipedia:WikiProject TechnologyTemplate:WikiProject TechnologyTechnology articles
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[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)reply
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)reply
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)reply
"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.)
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[1].
@
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)reply
Please read the relevant RFCs before making changes based on what the editor presumes is in them
Those are definitions[1] in
RFC5321. 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)reply
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)reply
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 (-).[1] Common advice is to avoid using some special characters to avoid the risk of rejected emails.[2] could well be expanded --
Shmuel (Seymour J.) Metz Username:Chatul (
talk)
15:34, 28 September 2022 (UTC)reply
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.
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)reply
References
^"Sign up for Windows Live". Retrieved 2008-07-26.. However, the phrase is hidden, thus one has to either check the availability of an invalid ID, e.g., me#1, or resort to alternative displaying, e.g., no-style or source view, in order to read it.
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)reply
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.
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)reply
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)reply
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)reply
One of the links that you provided, i.e., [
/rfc/rfc1035 RFC1035 for
RFC5325, is malformed; I recommend that you change all of the RFC citations to either {{IETF RFC}} or {{
cite ietf|rfc=}}
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īTALK11:04, 12 May 2023 (UTC)reply
There are two different IP questions that the article should discuss:
Is it valid to use an IP address as the domain part?
Is it prudent to have an IP address as the domain part?
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īTALK11:44, 12 May 2023 (UTC)reply
^P. Resnick, ed. (October 2008).
"Addr-Spec Specification".
Internet Message Format. p. 17. sec. 3.4.1.
doi:10.17487/RFC5322.
RFC5322. Retrieved May 12, 2023. 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.
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.
Some definitions in
RFC5321 refer to definitions in
RFC5322.
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.
>> 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)reply
@
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īTALK17:58, 3 April 2024 (UTC)reply
>> 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)reply
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)reply
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.
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)reply
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)reply
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)reply
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.”
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)reply
>> 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)reply
>> 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 […]”
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?
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)reply
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)reply
I believe that the article should state that e-mail address refers to either Mailbox (
RFC5321, only in Transport section) or to mailbox (
RFC5322), 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.
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)reply
Neither
RFC5321 nor
RFC5322 define email address or e-mail address.
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)reply
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)reply
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)reply
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@EasierReading.org</code> renders as FirstName.LastName@EasierReading.org
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)reply