ietf-smtp
[Top] [All Lists]

RFC2821bis new section 2.3

2005-08-22 02:51:41

I hereby post an new proposal for section 2.3 terminology from the
RFC2821bis draft.
draft-klensin-rfc2821bis-00.txt

In replying please reply to one section only and name the section number  in
the subjectline of your reply.


comments are placed  between [[ and ]]

Have a nice read.

Willemien

Index:
2.3  Terminology
2.3.A(new)  requirement levels
2.3.1  Mail Objects
2.3.1.1 (from 2.3.9) The SMTP envelope
2.3.1.2 (from 2.3.9) message SMTP-content
2.3.2  Senders and Receivers (unchanged)
2.3.B(new) originator
2.3.C(new) recipient
2.3.C.1 (new) postmaster recipient
2.3.3  Basic Mail Architecture / mail agents
(was Mail agents and message stores)
2.3.3.1 Mail User Agent MUA
2.3.3.2 Mail Submission Agent MSA
2.3.3.3 Mail Transfer Agents MTA
2.3.3.4 Mail Delivery agent MDA
2.3.3.5 Message Store   MS
2.3.D  Originator, Submission, Relay, Delivery, and Gateway Systems
2.3.D.1 Originator Systems
2.3.D.2 Submission Systems
2.3.D.3 Relay Systems
2.3.D.4 Delivery Systems
2.3.D.5 Gateway Systems
2.3.4  Host
2.3.5  Domain Names
2.3.6  Buffer and State Table
2.3.7  Lines
2.3.10   Mailbox and Address
2.3.11   Reply

The old section 2.3.8 is under 2.3.D
The old section 2.3.9 is under 2.3.2


2.3 Terminology

2.3.A(new) requirement levels

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

"may" "can" and other non-capitalised words refer to extensions that are
made in this draft and are not in RFC 2821 or other RFC's



2.3.1 Mail Objects

SMTP transports a mail object. A mail object contains an envelope and
content.


2.3.1.1 The SMTP envelope

The SMTP envelope is sent as a series of SMTP protocol units (described in
Section 3).  It consists of an originator address (to which error reports
should be directed); one or more recipient addresses; and optional protocol
extension material.  Historically, variations on the recipient address
specification command (RCPT TO) could be used to specify alternate delivery
modes, such as immediate display; those variations have now been deprecated
(see Appendix A.6 and Appendix A.6.6).


2.3.1.2 message SMTP-content

The SMTP content is sent in the SMTP DATA protocol unit. The terms
"message", "message content" and "mail data" are also referring to this term
and are used interchangeably in this document
They all describe the material transmitted after the DATA command is
accepted and before the end of data indication is transmitted.

Message content includes message headers and the possibly-structured message
body.  The MIME specification (RFC2979 [18]) provides the standard
mechanisms for structured message bodies.

The SMTP content is sent in the SMTP DATA protocol unit and has two parts:
the headers and the body.
 If the content conforms to other contemporary standards, the headers form a
collection of field/value pairs structured as in the message format
specification (RFC2822 [9]);

The headers MUST conform to RFC 2822 to form a collection of field/value
pairs structured as in the message format specification (RFC2822 [9]).

The body, if structured, MUST be defined according to MIME (RFC2045 [19]).
The content is textual in nature, expressed using the US-ASCII repertoire
[1].  Although SMTP extensions (such as "8BITMIME", RFC1652 [26]) may relax
this restriction for the content body, the content headers are always
encoded using the US-ASCII repertoire.  A MIME extension (RFC2047 [28])
defines an algorithm for representing header values outside the US-ASCII
repertoire, while still encoding them using the US-ASCII repertoire.

[[ in 3.1 and 3.2 message is used in another way {an 220 (welcome) message}
I suggest to change welcome message in these sections to server greeting.
Also in 4.2.2  and 4.2.3 there is mentioned an 214 help message reply,
If we can rename this to something else (without message) then message will
only refer to the message to be transferred ]]


2.3.2 remains Unchanged

2.3.B(new) Originator
For this draft the originator is the address that is indicated by the MAIL
command (see section XXX) because there can be messages that have an "null"
MAIL command (MAIL FROM:<>)
there can be messages without originator.
An message without originator MUST NOT be regarded as a fake email for this
reason only

The originators address is used to send the
notification message for an delivery failure.

Commonly the originator is also indicated by the RFC2822 /822 Sender: or
From: message header but for this draft only the originator as described in
the first paragraph is important.

If the originator is not "<>" the originator MUST be a valid address, SMTP
servers MAY reject messages if this address is malformed, has an
non-existent domain part, or without a FQDN.



2.3.C(new) recipient

For this draft the recipients are the addresses that are indicated by the
RCPT command (see section XXX) there can be messages that have more than one
recipient.

Commonly the recipients are also indicated by the RFC2822 /822 To: or Cc:
message header but for this draft only the recipients as described in the
first paragraph is important.

A Recipient can be a list, an alias or an mailbox, Only the delivery system
can know what it is, other systems MUST NOT change there behaviour according
to the recipient.


2.3.C.1(new) POSTMASTER recipient

All SMTP servers MUST support the reserved address [[was mailbox]]
"postmaster" as a case-insensitive local name.
The POSTMASTER address is the contact point for mail and mailserver
problems,

This postmaster address is not strictly necessary if the server always
returns 554 on connection opening (as described in Section 3.1).  The
requirement to accept mail for postmaster implies that RCPT commands which
specify a mailbox for postmaster at any of the domains for which the SMTP
server provides mail service, as well as the special case of "RCPT
TO:<Postmaster>" (with no domain specification), MUST be supported

SMTP systems are expected to make every reasonable effort to accept mail
directed to Postmaster from any other system on the Internet.
In extreme cases --such as to contain a denial of service attack or other
breach of security-- an SMTP server may block mail directed to Postmaster.
However, such arrangements SHOULD be narrowly tailored so as to avoid
blocking messages which are not part of such attacks.


[[ The first paragraph is a simplification and variation from section 4.5.1,
in the old version there are some more options NOT to have a postmaster
recipient although I did not see to what kind of SMTP servers this refers,
and in the old section 4.5.1 it did not say why you needed a postmaster
mailbox, mailbox is replaced by address]]

[[ looking at the impossibility to identify delivery servers, is it not an
idea to also include postmaster(_at_)hostname as a necessary mailbox to
support, ]]


2.3.3. Basic Mail architecture / Mail Agents

Since RFC 821 and RFC 2821 were published more specific mail terminology
became common.
Were convenient they are used in this specification.
This section describes the MUA (mail user agent) MSA (Mail submission
agent), the MTA (mail transfer agent) and the MDA (mail delivery agent) .
SMTP clients and servers provide a mail transport service and therefore
usually act as "Mail Transfer Agents" (MTAs).
While these terms are used with at least the appearance of great precision
in other environments, the implied boundaries between MUAs, MSAs, MTAs and
MDAs often do not accurately match common, and conforming, practices with
Internet mail. Hence, the reader SHOULD NOT infer strong relationships and
responsibilities that might be implied if these terms were used elsewhere.
In general implementations SHOULD NOT without reason assume that they are
only one of the Agent types described here. Full capacity SMTP servers
should be capable to provide all services off MSAs MTAs MDAs and provide MS.


2.3.3.1 (Mail) User Agent, MUA or UA

"Mail User Agents" (MUAs or UAs) are normally thought of as the sources and
targets of mail.
Common  Internet mail clients have limited capacity and are normally
arranged according a Split-(M)UA model, they use different protocols for
receiving and sending of mail.  For receiving POP3 or IMAP are the most
common protocols, while SMTP is used to send mail to an intermediate
receiving host. (MSA)

For this specification Mail User agents are comparable to limited capacity
originating systems (section 2.3.D.1.1)


2.3.3.2  Mail Submission Agent, MSA

MSAs are the SMTP-servers counterparts of (limited capacity) MUAs, they are
commonly intermediate servers that accept all messages from MUAs and process
them and takes responsibility of subsequent distribution.

For this specification Mail Submission agents are comparable to submission
systems (section 2.3.D.2)


2.3.3.3  Mail transfer agent, MTA

MTAs are the most common SMTP clients and servers they provide the transfer
of mail.

For this specification Mail Transfer Agents are comparable to relay and
gateway systems (see section 2.3.D.3 and section 2.3.D.5)

2.3.3.4 Mail Delivery Agent MDA

MDAs are the  final ("delivery") MTA and can 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 mailbox or "message store").
MDA's are also the agents that  interpret and (where necessary,) process the
local part of an address. The MDA takes care of forwarding, aliassing and
list expansion of addresses.

For this specification Mail Delivery Agents are comparable to delivery
systems (see section 2.3.D.4)



2.3.3.5 Message store,  MS

MDAs do the final SMTP- delivery by depositing the message in a mailbox or
"message store"
How an mailclient gets his messages from this mailbox falls outside this
specification.

For this specification Message Stores are part of delivery systems (see
section 2.3.D.4)



2.3.D  Originator, Submitter, Relay,  Delivery, and Gateway Systems

This specification makes a distinction among FIVE types of SMTP systems,
based on the role those systems play in transmitting electronic mail.
[[ sorry it became one more type ;-)]]



2.3.D.1 "originating" SMTP system

An "originating" system (sometimes called an SMTP originator, mail client,
(Mail) User Agent, MUA or UA) introduces mail into the Internet or, more
generally into a transport service environment.

There are two main types of "originating" SMTP systems:
Fully capable originating systems that are expected to support all of the
queuing, retrying, and alternate address functions discussed in this
specification. [[ and they SHOULD also  conform to all regulations for
internet hosts,to be described in section 2.3.4]]

and

Limited capable originating systems that are that transfer all traffic
[[messages??]], regardless of the target domain names associated with the
individual messages, or that do not maintain queues for retrying  message
transmissions or that do not or cannot conform to all regulations for
internet hosts.


2.3.D.1.1 Limited capable originating system

For Limited capable originating systems it is common practice to make
private arrangements to send all messages to a single server for processing
and subsequent distribution, an "submitter" SMTP system.(see below section
2.3.D.2)
SMTP, as specified here, is widely used but not ideally suited for this
role, and standardised mail submission protocols are being developed that
might eventually supersede the current practices (see, e.g., RFC2476 [22]).
In any event, because these arrangements are private and fall outside the
scope of this specification, they are not fully described here.

In any case, restricted-capability clients MUST NOT assume that any SMTP
server on the Internet can be used as their mail processing (relaying) site.

Not-fully capable originating systems SHOULD send all their messages to the
"submitter" SMTP system with which it has made a
private arrangement.

Limited capacity systems are further described in section XXX [[to make]]


2.3.D.2  "submitter" SMTP system
[[ in section 2.1 there is a pointer to section 2.3.8 that should point to
this section]]

"submitter" SMTP systems receive messages from a not-fully capable
originating systems and transfer them according this specification to there
destination.

"submitter" SMTP systems SHOULD have a prior arrangements and MUST do some
kind of authorisation with the "originator" SMTP clients from which they
accept messages. This can be done by SMTP over Transport Layer Security
(RFC3207), SMTP authorisation (RFC 2554), testing the Clients IP address
(from the TCP-info) or other ways

"submitter" SMTP systems SHOULD NOT relay mail from originators with which
it has no agreement to do so. (see the section on Open Relays,)

SMTP, as specified here, is often used but not ideally suited for this role,
and standardised mail submission protocols are being developed that might
eventually supersede the current practices (see, e.g., RFC2476 [22] and
RFC2476bis.).  In any event, because the arrangements between originator
system and submitter system  are private they fall outside the scope of this
specification, they are only informally described here.

"submitter" systems have functionality's that differ from the other SMTP
systems and are were they differ from the other systems specified in section
XXX

[[I think it is a good idea to put all "special" regulations for submitter
systems in one (big) section and that the rest of the draft only specifies
the other SMTP systems, (except many pointers to that section and
subsections....) ]]

SMTP servers that only supports submitting SHOULD NOT have MX records
pointing at them.

Although fully capable SMTP systems [[a term used in section 2.1]] may allow
message submitting it is recommended to have separate hosts for submitting
see [RFC 2476]


2.3.D.3  "relay" SMTP system
A "relay" SMTP system (usually referred to just as a "relay") receives mail
from an SMTP client and transmits it, without modification to the message
data other than adding trace information, to another SMTP server for further
relaying or for delivery.
"relay" SMTP systems differs from "submission" SMTP systems that there are
MX pointers pointing at relay systems, relay systems SHOULD NOT modify the
message data other than adding trace information, to another SMTP server for
further relaying or for delivery.
[[ in other words "submission" servers belong to the
mail-originating-network, relay servers belong to the
mail-recipients-network, but these terms are not RFC either they are from
http://www.cs.utk.edu/~moore/opinions/email-submission-recommendations.html
work in progress]]



2.3.D.4  "delivery" SMTP system

A "delivery" SMTP system is one that receives mail from a transport service
environment and passes it to a mail user agent or deposits it in a message
store which a mail user agent is expected to subsequently access.

A "delivery" SMTP system is the only system that can interpret the localpart
of an address, a "delivery" system therefore the only system that can give
an "authoritative" reply to the VRFY and EXPN commands for his particular
domain.
The "delivery" system takes care of forwarding, aliassing and list expansion
of addresses, and can therefore reintroduce messages in the transport
service environment.

DISCUSSION
An problem is that it is not possible for an common SMTP client to know if
he is transferring to an delivery or an relay system, This implies that the
client can not know if he has got an "authoritative" reply to an VRFY and
EXPN commands.

[[ section 5 mentions a "designated Mail eXchanger" is that an other name
for a "delivery" SMTP system]]


2.3.D.5 "gateway" SMTP system

A "gateway" SMTP system (usually referred to just as a gateway")
receives mail from a client system in one transport environment and
transmits it to a server system in another transport environment.
Differences in protocols or message semantics between the transport
environments on either side of a gateway may require that the gateway system
perform transformations to the message that are not permitted to SMTP relay
systems.
For the purposes of this specification, firewalls that rewrite addresses
should be considered as gateways, even if SMTP is used on both sides of them
(see RFC2979 [18]).
Gateways are described in appendix XXX
[[they are not necessary in the main body of the draft]]


[[Note in draft/Placeholder: There has been a request to expand this
section, possibly into a more extensive model of Internet mail. Comments
from others solicited.]]


2.3.4  Host
[[ added requirements]]


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 address.
Fully capable SMTP systems MUST conform to the following requirements:

For fully capable SMTP Clients:
The hostname given in the EHLO or HELO command  MUST resolve in a DNS A
record.
That A record MUST point to the SMTP Client.
And the IP address of the SMTP client MUST resolve back to the hostname.

For fully capable SMTP Servers:
The hostname given in the server greeting [[was welcome message]] MUST
resolve in a DNS A record.
That A record MUST point to the SMTP server.
And the IP address of the SMTP server MUST resolve back to the hostname.


2.3.5  Domain Names
[[changed last line]]

A domain name (or often just a "domain") consists of one or more
dot-separated components.  These components ("labels" in DNS terminology,
RFC1035 [5]) are restricted for SMTP purposes to consist of a sequence of
letters, digits, and hyphens drawn from the ASCII character set [1].  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 RFC1035 [5] and Section 5 of this specification.

The domain name, as described in this document and in RFC1035 [5], 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 A RRs (as discussed in Section 5) are permitted, as
are CNAME RRs whose targets can be resolved, in turn, to MX or A RRs.  Local
nicknames or unqualified names MUST NOT be used.
An exception is the domain name given in the EHLO command this MUST be a
primary host name (a domain name that resolves to an A RR)


DISCUSSION
in the old draft also address literal are allowed.
These should only be allowed for limited capacity systems and not for fully
capable systems, therefore this exception should be stated in section XXX
about limited capacity systems, not in the main section.


2.3.6 Unchanged

2.3.7 Unchanged

2.3.8 replaced by section 2.3.D

2.3.9 submerged in section 2.3.1

2.3.10  Mailbox and Address
[[last line is changed]]

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(_at_)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 optimise transport by modifying them, the local-part MUST
be  interpreted and assigned semantics only by the delivery system that
takes care of  the domain part of the address.
[[last line is changed]]

2.3.11   Reply  unchanged




<Prev in Thread] Current Thread [Next in Thread>