Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Simple Mail Transfer Protocol.docx
Скачиваний:
9
Добавлен:
22.02.2015
Размер:
61.63 Кб
Скачать

2.3.3. Mail Agents and Message Stores

Additional mail system terminology became common after RFC 821was

published and, where convenient, is used in this specification. In

particular, SMTP servers and clients provide a mail transport service

and therefore act as "Mail Transfer Agents" (MTAs). "Mail User

Agents" (MUAs or UAs) are normally thought of as the sources and

targets of mail. At the source, an MUA might collect mail to be

transmitted from a user and hand it off to an MTA; the final

("delivery") MTA would be thought of as handing the mail off to an

MUA (or at least transferring responsibility to it, e.g., by

depositing the message in a "message store"). However, while these

terms are used with at least the appearance of great precision in

other environments, the implied boundaries between MUAs and MTAs

often do not accurately match common, and conforming, practices with

Internet mail. Hence, the reader should be cautious about inferring

the strong relationships and responsibilities that might be implied

if these terms were used elsewhere.

2.3.4. Host

For the purposes of this specification, a host is a computer system

attached to the Internet (or, in some cases, to a private TCP/IP

network) and supporting the SMTP protocol. Hosts are known by names

(see the next section); they SHOULD NOT be identified by numerical

addresses, i.e., by address literals as described in Section 4.1.2.

2.3.5. Domain Names

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 5of 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.3and 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.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]