A domain name (or often just a "domain") consists of one or more
components, separated by dots if more than one appears. In the case
of a top-level domain used by itself in an email address, a single
string is used without any dots. This makes the requirement,
described in more detail below, that only fully-qualified domain
names appear in SMTP transactions on the public Internet,
particularly important where top-level domains are involved. These
components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
for SMTP purposes to consist of a sequence of letters, digits, and
hyphens drawn from the ASCII character set [6]. Domain names are
used as names of hosts and of other entities in the domain name
hierarchy. For example, a domain may refer to an alias (label of a
CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See RFC 1035 [2]
and Section 5 of this specification.
The domain name, as described in this document and in RFC 1035 [2],
is the entire, fully-qualified name (often referred to as an "FQDN").
A domain name that is not in FQDN form is no more than a local alias.
Local aliases MUST NOT appear in any SMTP transaction.
Only resolvable, fully-qualified domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed
in Section 5) are permitted, as are CNAME RRs whose targets can be
resolved, in turn, to MX or address RRs. Local nicknames or
unqualified names MUST NOT be used. There are two exceptions to the
rule requiring FQDNs:
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
|
|
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
o The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see Section 4.1.1.3) and
MUST be accepted if so used.
Buffer and State Table
SMTP sessions are stateful, with both parties carefully maintaining a
common view of the current state. In this document, we model this
state by a virtual "buffer" and a "state table" on the server that
may be used by the client to, for example, "clear the buffer" or
"reset the state table", causing the information in the buffer to be
discarded and the state to be returned to some previous state.